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ABSTRACT 

A parallel program may be indeterminate so that it can 
adapt its behavior to the number of processors available, or 
at least so that low level timing issues are removed from the 
program. 

Indeterminate programs are hard to write, understand, 
modify or verify. They are impossible to debug, since they 
may not behave the same from one run to the next. 

We propose a new construct, a polymorphic abstract data 
type called an improving value, with operations that have 
indeterminate behavior but simple determinate semantics. 
These operations allow the type of indeterminate behavior 
required by many parallel algorithms. 

We define improving values in the context of a functional 
programming language, but the technique can be used in 
procedural programs as well. 

1 INTRODUCTION 

A parallel program may be indeterminate so that it can 
adapt its behavior to the number of processors available, or 
at least so that low level timing issues are removed from the 
program. 

For example, in a combinatorial search, many different 
processes may be searching different subspaces in parallel. 
These processes may all access and update a global variable 
that gives information on the best solution found so far. 
The current value of the variable may be used to determine 
if a subspace may be pruned from the search. Since the 
processes are not synchronized, the pruning of a particular 
subspace may depend on just when a shared variable is read. 
This causes indeterminate behavior, although the final result 
may be determinate. 

Indeterminate programs are hard to write, understand, 
modify or verify. They are impossible to debug, since they 
may not behave the same from one run to the next. 

We propose a new construct, a polymorphic abstract data 
type called an improving value, with operations that have 
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indeterminate behavior but simple determinate semantics. 
These operations allow the type of indeterminate behavior 
required by many parallel algorithms. Operationally, we 
may know a lower bound (or upper bound) for an improv- 
ing value at any given time. If this bound is sufficient, we 
may act on it. Otherwise, the bound may improve as the 
computation proceeds. 

We define improving values in the context of a functional 
programming language, but the technique can be used in 
procedural programs as well. We will user the notation of 
the Miranda 1 functional programming language [7, 8, 9]. 

In section 2 we will briefly review the concept of specula- 
tive evaluation. The improving value abstract data type will 
be introduced in section 3. Several examples of the use of 
improving values are given in section 4, including a parallel 
least-cost search algorithm that is only four line long. In 
these three sections we will limit our attention to two types 
of computing devices: Those with a single processor and 
those with an infinite number of processors. Since machines 
of the second type are not yet on the market, in section 5 
we will consider how to make best use of a limited number 
of processors. The least-cost search algorithm will again be 
considered. An axiomatic definition of improving values is 
given in section 6, along with several properties of improving 
values, and an outline for a simple correctness proof for the 
least-cost search algorithm. Section 7 is the conclusion. 



2 SPECULATIVE EVALUATION 

Often it is necessary for a good parallel algorithm to per- 
form more work in total than would be performed by a good 
sequential algorithm for the same problem. This is because 
the best sequential algorithm may not have a very high po- 
tential for parallelism. In other cases, the sequential algo- 
rithm may have a high potential for parallelism, but only if 
some work is done before it is know to be required. We are 
interested in algorithms of this second kind. 

Recall that, by definition, any problem in NP can be 
solved by a nondeterministic Turing machine in polynomial 
time. Consider any NP-complete problem, and any nonde- 
terministic polynomial time algorithm to solve the problem 
where none of the nondeterministic choices lead to a non- 
terminating computation. A sequential algorithm for this 
problem can be produced by simulating the nondetermin- 
ism by backtracking. In the worst case, we will have to do 
an exhaustive search using the backtracking algorithm. No 



1 Miranda is a trademark of Research Software Ltd. 



340 



spec.or a b = spec (or a) b 
where 

or a b = a V b 



start (x-.xs) — spec (spec cons x) (start xs) 
where 

cons a b = a:b 



Figure 1: Two useful functions for initiating speculative 
computation. 



other sequential algorithm can solve this problem in poly- 
nomial time in the worst case, assuming P ^ NP. 

With unbounded parallelism, we can solve any NP- 
complete problem in polynomial time by considering all of 
the alternatives of the nondeterministic choices in parallel. 
Since no sequential algorithm has a worst case polynomial 
time solution, all NP-complete problems' have a high po- 
tential for parallelism. On the other hand, the backtracking 
algorithm could go directly to the solution, solving the prob- 
lem as quickly as with unbounded parallelism, in the best 
case. Hence we have an example of a problem where we can 
gain speed through the use of parallelism, in the average 
case, but only if we are willing to perform some work that 
may not be required. 

The use of speculative evaluation [1, 2, 3] has been pro- 
posed for problems such as this. A speculative computation 
is a computation that may or may not be required later. For 
example, while considering one alternative in a backtracking 
algorithm, speculative computations may be exploring other 
alternatives. 

All computation that is not speculative is called manda- 
tory. If a speculative computation is found not to be re- 
quired, then it may be terminated. If a speculative compu- 
tation is found to be required, then it must be upgraded to 
mandatory. Mandatory computation must be favored over 
speculative computation, at least to the extent that some 
mandatory computation is always progressing. In the de- 
generate case of a single processor, no speculative computa- 
tion will ever be performed. With unbounded parallelism, 
all speculative computation will be performed, at least until 
it is found to be not required. 

A single function spec is sufficient to introduce speculative 
evaluation. The type of spec is 

spec :: (* -> **) -> (* -> **) 

and semantically it is the identity function restricted to func- 
tions. That is 

spec fx = fx 

Operationally, spec will initiate the speculative evaluation of 
its second argument before applying its first argument to its 
second. 

Two useful functions are denned in Fig. 1. The function 
spec.or is denned in terms of the conditional or operator, 
V. When applied, spec.or will evaluate its first argument 
as a mandatory computation and its second argument as 
a speculative computation. It the first argument returns 
True then the speculative computation may be terminated 
by the implementation. If the first argument evaluates to 



abstype improving * 
with 

make :: * -> improving* 
break :: improving * -> * 

minimum :: improving * -> improving * -> improving 
spec.max :: improving * -> improving * -> improving 



Figure 2: Signature of type improving. 



False then the speculative evaluation must be upgraded to 
mandatory if it has not already completed. This function 
could be useful in a simple backtracking algorithm that re- 
turns a boolean result. The function start will initiate the 
speculative evaluation of all of the elements in the list to 
which it is applied. In Miranda, the colon is an infix cons 
operator- 
Examples of speculative algorithms may be found in [2]. 

3 IMPROVING VALUES 

Often in combinatorial search algorithms, bounds are main- 
tained to help decide when pruning is possible. For example, 
in a branch- and-bound search for a least cost solution, a pro- 
gram may keep the value of the best solution found so far. 
If it is possible to establish that a subspace can not return 
a better solution, it can be pruned. Alpha-beta search, and 
similar algorithms, also maintain bounds. In all of these 
cases, the values of the bounds change monotonically as the 
computation progresses. We will limit our attention to lower 
bounds. Upper bounds can be handled in a similar manner. 

We proposed the use of the polymorphic abstract data 
type improving for a lower bound that may improve (become 
a tighter bound) over time. The type signature is given in 
Fig. 2. 

The functions make and break are type transfer func- 
tions, and minimum and spec.max compute the minimum 
and maximum of improving values, respectively, with some 
added laziness. 

We will be able to use the result returned by spec.max 
before its second argument has been evaluated if its first ar- 
gument provides sufficient information, just as we are able 
to use the result returned by spec.or before its second ar- 
gument has been evaluated provided its first argument is 
True. In general, once the first argument of spec.max has 
been evaluated, we will have a lower bound on the result. If 
this is not sufficient, we can wait for the bound to improve, 
which will happen when the value of the second argument 
is available. 

For example, 

break (minimum (make 5) (spec.max (make 7) ±)) = 5 

Here J. denotes an undefined value or a nonterminating 
computation. We cannot test a value for equality with J., 
since the halting problem is undecidable. In practice, we are 
not really concerned with handling nonterminating compu- 
tations or undefined values. However, if any subexpression 
of an expression can be replaced by _L without changing the 
value of the expression, then the subexpression need not be 
evaluated. 

In practice, it is better to parameterize the improving ab- 
stract data type with an order relation. This will permit im- 
proving values to be used for upper bounds as well as lower 
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improving *==[*] 
make a = [o] 
break x = last x 

spec-max xa ys = spec (monotonic-append xs) ys 

minimum xs ys = short-merge xs ys 

monotonic-append [x] ys = x : dropwhile (<= x) ys 
monotonicappend (x:xs) ys 

= x : monotonicjappend xs ys 

short-merge [][] = [ J 
short-merge (x:xs) [ ] = [ ] 
short-merge [ ] (y.ys) = [ ] 
short-merge (x-.xa) (y.ys) 

= x: short-merge xs ys, if x = y 

= x-.shortjmerge xs (y.ys), if x < y 

= y.short-merge (x-.xa) ys, if x > y 



Figure 3: A simple implementation of improving. 



bounds. This also will support applications that require or- 
der relations other than those build into the language. This 
change is straight forward, but complicates the presentation 
slightly, so will be omitted. In this paper, for simplicity, 
we will rig all of our examples so that the *<" operator, 
which is provided for all types in Miranda, gives the desired 
ordering. 

An improving value can be represented by a strictly in- 
creasing hst of approximations. The final element of the list 
will be the true value that previous list elements approx- 
imate. Infinite lists and partial lists will be considered in 
section 6. We will assume that for any two values a and b, 
the value of a < 6 is defined. 

With this representation, the improving abstract data 
type can be implemented as shown in Fig. 3. The func- 
tion make produces a singleton hst, and break returns the 
last element of a list. The spec.max function starts the spec- 
ulative evaluation of its second argument and then appends 
its arguments, removing any values in the second hst that 
are less than or equal to the final element of the first hst. 
This insures that the list of approximations remain strictly 
increasing. On the other hand, minimum merges two lists, 
removing duplicates in order to maintain strict monotonic- 
ity. In addition, the merge ends as soon as either hst ends. 
For example, 

minimum (make 4) (spec.max (make 3) (make 5)) 

will cause the lists [4] and [3, 5] to be merged to produce [3, 
4], with the 5 thrown away. As a second example, 

minimum (make 4) (spec-max (make 5) (make 3)) 

will result in the two singleton lists [4] and [5] being merged 
to produce the singleton list [4]. The 3 will be discarded by 
spec-max since it would be out of order, and the 5 will be 
discarded by minimum as before. 

We will sometimes refer to the elements of a list represent- 
ing an improving value as a progress report. Each progress 
report gives some new information about the final value of 
an improving value. 



It is easy to see that every element of a hst representing 
an improving value, except for the final element of the hst, 
must at some time have occurred in a left argument of an 
application of spec.max. This property is trivially true of 
the singleton lists produced by make, and is preserved by 
minimum and spec-max. Often it is useful to use the ex- 
pression spec-max a b in situations where b is the desired 
result, but a is known to be a lower bound on the result. In 
this case, a is a progress report. 

If the abstract type improving is implemented as a lan- 
guage primitive, then a more efficient implementation than 
the one described above is possible. Each improving value 
is represented by a pair consisting of the best approxima- 
tion found so far and a flag indicating whether this is a final 
value. Each improving value has an associated process that 
will update the approximation as required and supply the 
latest value to other processes upon request. This save stor- 
ing more than one value and saves other processes the cost 
of examining out of date values before coming to the most 
recent value. In some cases this can significantly reduce the 
amount of communication between processes. 

4 EXAMPLES 

In this section we will consider parallel versions of three 
search algorithms. 

4.1 Least-Cost Search 

With many combinatorial problems it is necessary to search 
a solution space for the best solution to the problem. We 
will assume that "best" means "smallest" and call the mea- 
sure of a solution the cost of the solution. Horowitz and 
Sahni present a least-cost search algorithm for this prob- 
lem [5]. Assuming the costs of leaves and lower bounds for 
other nodes are all distinct, this algorithms expands exactly 
the same nodes as the A * algorithm in the case of a single 
processor, which is optimal [6]. 

We will assume that the solution space is organized as a 
tree with all possible solutions at leaves. For any node, node, 
isJeaf node is a 600/ indicating whether or not the node is a 
leaf. For any leaf node, cost node is the cost of the solution. 
If the node is not a leaf, then children node is a fist of the 
children of node and lower-bound node is a lower bound on 
the least cost solution to be found in the subtree rooted at 
node. Finally, niLnode is a special node such that nil-node 
< node for any node, node, that may be encountered during 
a search. Otherwise nodes are ordered arbitrarily. 

Let us first consider a simple exhaustive search algorithm 
to solve this problem. Such an algorithm is given in Fig. 
4. The function returns an ordered pair, consisting of the 
cost of the best solution together with that solution. Note 
that if costl < cost2 then (costl, nodel) < (cost2, node2) in 
Miranda. We should note that "." is an infix function com- 
position operation and foldrl is a function that will apply 
a binary function to elements of a list, reducing the list to 
a single value (e.g. foldrl (+) xs will compute the sum of 
the elements of the hst xs). We will use mint and maxi for 
binary minimum and maximum functions, respectively. The 
function map will apply a function individually to elements 
of a hst, producing a new list. 

Fig. 5 gives an equivalent (but slightly less efficient) ver- 
sion of this search. We know that lower-bound root is a 
lower bound on the cost of the node returned by searching 
the subtree rooted at root and, in case it is a tight lower 
bound, niLnode is less than any other node. It follows that 
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search root 

= (cost root, root), if isJeaf root 

= (foldrl mini.map starch. children) root, otherwise 



Figure 4: An exhaustive search algorithm. 



(lower-bound root, niLnode) < 

(foldrl mini.map search. children) root 

so the two algorithms must return the same result. 

A minor further modification, to introduce improving val- 
ues, yields the least-cost search algorithm in Fig. 6. Notice 
how the search of each subtree starts by providing a progress 
report in the form of a lower bound on the best solution to 
be found in the subtree. If a better solution has been found 
anywhere in the tree, this progress report is sufficient for the 
subtree to be pruned. 

In the case of a single processor, where no speculative 
evaluation is performed until it becomes mandatory, only 
those nodes with a lower bound less than or equal to the 
cost of the optimal solution can ever be expanded. Hence, 
in the sequential case this algorithm is optimal with respect 
to the number of nodes expanded, assuming all costs and 
lower bounds are distinct. With an unbounded number of 
processors, all paths are searched in parallel, at least until a 
least cost solution is found. 

4.2 Breadth-First Search 

Fig. 7 shows a parallel breadth-first search algorithm. The 
algorithm takes a node as a parameter and returns a pair 
consisting of the depth of a least deep solution and the so- 
lution itself. We assume that we are given two functions: 
issohtion, which determines whether a node is a solution 
to the problem of interest, and children, which will generate 
a list of the children of a node. We do not require that a 
solution be a leaf node. As with the least-cost search al- 
gorithm, we assume the existence of a node niLnode. We 
also assume the existence of a value infinity which is greater 
than the depth of any reasonable search. This simplifies the 
algorithm and allows us to use the built in order relation 
"<". Notice that we have used the function start defined in 
Fig. 1 to initiate the parallel searching of all subtrees when 
the subtree root has been found not to be a solution. A 
subtree is pruned whenever a progress report is sufficient to 
eliminate it from consideration. That is, if the local search 
is at a greater depth than a know solution, it is terminated. 

4.3 Alpha-Beta Search 

As a final example we will consider a parallel alpha-beta 
search algorithm for searching a game tree, based on the se- 
quential alpha-beta search algorithm given in [5], For sim- 
plicity, the algorithm returns the value of the best move, not 
the move itself. Again start is used to initiate the searching 
of subtrees. The algorithm is given in Fig. 8. 

We assume the existence of three functions. The function 
isJeaf determines whether a node is a leaf. For leaf nodes 
eval computes the value of the node to the player whose turn 
it is, and for other nodes children computes the children of 
the node (of which we assume that there is at least one.) 

The function scan is a commonly used function, similar 
to foldrl, but returning a list of "partial sums" rather than 
just the final "sum". It is defined by 



= a : scan' f a xs 
where 

scan'fa[} = \} 

scan' f a (x:xs) ~ scan f (f a x) xs 

The function zip2 maps two lists into a list of corresponding 
pairs, ending as soon as either list ends. 

The expression (alpha.beta node alpha beta) searches for 
the value of the best move for the player whose turn it is, 
subject to the constraint that only moves with value between 
alpha and beta are considered. We know that by making a 
different move, we can get to a position with value at least 
alpha, and also know that our opponent can keep us from 
getting to a position of value greater than beta by making a 
different move earlier. The initial call is of the form 

alpha-beta root (— m) m 

where m is choosen such that for any position, p, 

— m < eval p < to. 

The list alphas is the list of alpha values that result after 
the search of each child. The recursion allows each element 
of this list to be used as a bound in the computation of the 
next element. 

Parallel algorithms for minimax searching is an active 
area of research. This simple parallel alpha-beta algorithm 
is probably not the best solution to the problem. Our no- 
tation makes it easier to understand and verify algorithms, 
but fundamental problems of finding the best algorithm for 
a given problem remain. 

5 PRIORITIES 

If all computation is mandatory, then scheduling is not a 
difficult problem, assuming a shared memory of sufficient 
size, so we do not need to worry about communication be- 
tween processors or running out of memory. There are sim- 
ple scheduling algorithms [4] that are, in the worst case, 
within a factor of two of being optimal, where we measure 
the quality of a scheduling algorithm by the time required 
to finish all computation. 

This is not true with speculative computation. If we have 
n processors and a potential for parallelism that is much 
higher than n, then it is possible for some problems to get a 
speedup approaching n if all processors do mandatory work 
or speculative work that will later become mandatory almost 
all of the time. On the other hand, if one processor does 
mandatory work and all other processers spend almost all of 
their time on speculative computation that will prove to be 
unneeded, then the speedup may not be much greater than 
one. Clearly, given a limited number of processors, we prefer 
to do that speculative work that is most likely to be required 
later. In general, it is not possible for the implementation 
to determine which speculative computations are the most 
worthwhile. 

The solution to this problem is to let the programmer 
specify priorities. We can introduce a new function, priority 
of type num -> * -> *. The semantics of priority are 

priority n x — -L, if n = X 

= x, otherwise 

If priority is called within a speculative computation, it 
initiates a new speculative computation with priority n, 
where n is any number, to compute x. The higher the value 



search root 

— (cost root, root), if isjeaf root 

= maxi (lowerJaound root, niLnode) ((foldrl mini.map search. children) root), otherwise 



Figure 5: A modified exhaustive search algorithm. 



search = break. search' 
search' root 

= make (cost root, root), if isJeafroot 

= spec.max (make (lower-bound root, niLnode)) ((foldrl minimum.map search'. children) root), otherwise 



Figure 6: A least-cost search algorithm. 



breadth-first = break.search 0 
search depth root 

=s make (depth, root), if is^olution root 

= make (infinity, niLnode), if kids = [ ] 

— spec-max progress-report solution, otherwise 
where 

kids = children root 

progress-report = make (depth, niLnode) 

solution = foldrl minimum (start [aeorcA (depth + 1) k | k <- kids]) 



Figure 7: A parallel breadth-first search algorithm. 



alpha-beta root alpha beta 

= eval root, if isJeaf root 

= break (minimum (make beta) best), otherwise 
where 

best = (foldrl spec-max.map make) alphas 
alphas = spec (scan maxi alpha) (start searches) 

searches = [ - (alpha-beta child ( - beta) ( - new.alpha)) \ (child, new-alpha) <- zip2 (children root) alphas] 



Figure 8: An alpha-beta search algorithm. 
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of n, the higher the priority of the speculative computation. 
All speculative computations started with spec have higher 
priority than any started by priority. The priority of a spec- 
ulative computation can not be changed, except that the 
speculative computation may become mandatory. In partic- 
ular, when one speculative computation finds it needs the 
result of another, possibly lower priority, speculative compu- 
tation in order to proceed, it must wait for the second spec- 
ulative computation to finish (unless, of course, the waiting 
computation becomes upgraded to mandatory.) Of course, 
if priority is invoked by a mandatory computation, then the 
resulting computation will immediately become mandatory, 
since it would not have been invoked if its result were not 
needed. 

As an example, we could modify the least-cost search al- 
gorithm in Fig. 6 by changing the subexpression 

(foldrl minimum. map search '.children) root 

to 

(priority (—(lowerJbound root)). 

foldrl minimum.map search '.children) root 

so that nodes that are more promising (have a smaller lower 
bound on the least cost solution) are expanded with higher 
priority. (Of course, we would want to factor out the com- 
putation of lower-bound root and compute it only once.) 

6 FORMAL PROPERTIES 

We will assume that the values used in improving values are 
finite in size and come from a flat domain. That is, values are 
either completely defined or are X. An example of a nonflat 
domain would be the domain of lazy lists. For example, the 
lazy list 1:X has 1 as its first element, but any attempt to 
evaluate the tail of the list will result in a nonterminating 
computation or an undefined result. 

If we allow values from a nonflat domain to be improving 
values, we have some awkward special cases. For example, 
with fists ordered in the obvious way, 

break (minimum (make (1:X)) 

(spec.max (make (1:X)) (make (2:X)))) 



since the comparison of (1:JL) with (1:X) will not terminate. 
On the other hand, 

mint (1:_L) (maw (1:X) (2:X)) = 2:X. 

In this case, maxi is applied first and the nonterminating 
comparison does not arise. Similar problems can arise with 
infinite lists. We would like the improving value operations 
to be at least as well defined as the corresponding operations 
on ordinary values. 

Sometimes it will be useful to have improving values 
where values come from a flat subdomain of a nonflat do- 
main. For example, we might want to use improving lists 
in a context where we know that all lists will be finite and 
well defined. In section 4, we used improving ordered pairs. 
The domain of ordered pairs is not flat, since it includes el- 
ements such as (1, J_). However, we only used fully defined 
ordered pairs. In cases such as these, we must restrict our- 
selves to a flat subdomain. If type improving is implemented 
as a primitive in a language, the restriction to finite, fully 
defined values can be enforced by requiring make to fully 
evaluate its argument. The results in the remainder of this 



section depend on values being finite and either fully defined 
or completely undefined before make is applied. 

With the implementation of type improving given in Fig. 
3, a number of different lists may all represent the same 
abstract object. Recall that lists are strictly increasing se- 
quences of improving approximations. If a and b are any 
two well defined values with a < b then it is not possible to 
distinguish a:i>:xs from b:xs provide b:xs is a valid represen- 
tation for an improving value. Since spec.max and minimum 
both examine fist elements sequentially, lists of the form xs 
++ X ++ ys, where "++ " is an infix append operator, can- 
not be generated, although lists of the form xs ++ J_ can 
be produced. Finally, while both [X] and X are possible 
representations for improving values, a:[±] is not a possible 
representation. For example, spec.max (make a) (make X) 
will produce an improving value represented by a:X, even 
though make J. produces [Xj. 

With these observations, we can divide representations 
into equivalence classes. We will let a! represent the class 
of all finite, fully defined lists with final value a. If xs is a 
member of the equivalence class a!, then we will represent 
the equivalence class that includes xs ++ X by a+7. We 
will read o! as "exactly a", and «+? as "at least a". Both 
[-L] and X belong to the same equivalence class which we 
will represent by X. 

Finally, we have two cases to consider with infinite fists. 
An infinite list having no upper bound on the size of its 
elements is in an equivalence class represented by oo. An 
infinite list where the elements have a least upper bound, 
a, is a member of the equivalence class represented by o-e, 
which is read "almost a". For example foldrl spec-max (map 
make [1..]) will generate oo. 

Axioms for improving values are given in Fig. 9. In this 
figure, a and 6 may represent any values and x may represent 
any improving value. 

With these axioms, we can prove a number of interesting 
properties. These include: 

make (mini a b) = minimum (make a) (make b) (1) 
make (maxi a b) C specjmax (make a) (make b) (2) 
mini (break a) (break b) c break (minimum a b) (3) 
maxi (break a) (break b) = break (specmax a b) (4) 
breafc.mafce = id (5) 
make.break C id (6) 

We can use these properties to prove the correctness of ef- 
ficient combinatorial search algorithms using improving val- 
ues. To show that an implementation meets its specifica- 
tion, we show that specification C implementation. That is, 
where the specification is defined, the implementation must 
agree with it, but the implementation may be stronger. For 
example, we may take an exhaustive search algorithm as a 
specification for a more efficient search algorithm that avoids 
searching unnecessary subspaces. In these cases, the imple- 
mentation must exceed the specification, because nontermi- 
nating computations in the pruned portion of the search 
space will be unencountered by the implementation, but 
would cause the specification to fail to terminate. 

If we take the algorithm in Fig. 4 as a specification for 
the more efficient least-cost search algorithm of Fig. 6, then 
we can easily prove the least-cost search algorithm correct. 
First we recall that the algorithm in Fig. 5 is equivalent to 
the one in Fig. 4. Using properties 6, 1, 2 and 5 above, it is 
easy to show that the least-cost search algorithm meets its 
specification. 
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make X = X 
make a = a! 

break X = X 
ftreafc a! = a 
ireafc «+? = X 
ireafc a-e = X 
break oo = X 

minimum ab = minimum b a 
minimum X x = X 
mt'nimitm 001=1 

minimum a! 6! = if a < 6 then a! else 6! 
minimum a! 6+? = if a < 6 then a! else A+? 
minimum a! 5-e = if a < & then a! else 6-e 
minimum a+? i+? = if o < 6 then a+? else &+? 
mmimiim a+? b-e = if a < 6 then a+? else 5-e 
minimum a-e &-e = if a < fe then a-e else &-e 

apec.max X 2 = X 
specjmax 00 x = 00 
3j>ec_max o+? x — o+? 
apecjmax a-e x = a-e 
specjmax a! X = o+? 
specjmax a! 00 = 00 

specjnax a! b! = if a < i then 6! else a! 
specjnax a! 4+? = if a < b then &+ ? else a+? 
specjmax a! fr-e = if a < 6 then b-e else a+? 
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Figure 9: Axioms for type improving. 



7 CONCLUSION 

We have seen that the polymorphic abstract data type im- 
proving allows us to express various combinatorial algo- 
rithms in a manner that is simplier than most previous ex- 
pressions, yet at the same time introduces parallelism into 
the problem. Furthermore, the type improving has an ax- 
iomatic specification from which we can derive several im- 
portant properties, which in turn can be use to prove the 
correctness of programs using the type. 

As an example, we presented a four line function for a 
parallel least-cost search that is optimal on a single processor 
and can make good use of any number of processors. A 
correctness proof of the function was outlined and can be 
easily completed by the reader. 
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